Pass your certification exam. Faster. Guaranteed.

PKI - Key Management Transcription

Welcome to our public key infrastructure key management process module. There is a lot to consider with key management in a public key infrastructure. First, we have to generate the keys. Which is where we create the key pair. Including a public key and a private key for the user.

We also must determine the strength of the key that we are going to use and the cipher that we are going to choose. Some certificate authorities will generate the keys for the user. And others will allow the user to generate their own key pair and then upload it to the certificate authority so that certificate authority does not have a copy of the key.

The certificate is generated typically using the user's public key so that others can verify the information. The certificate authority will perform identity verification, and they can also delegate this process to the registration authority. Either way, the identity must be verified before a certificate is issued. Once the certificate is issued, then the key, or certificate, or both must be given to the user in some fashion.

A suspension is a temporary hold put on credentials such as if a user goes on vacation. Revocation renders the certificate permanently useless and the certificate is added to the certificate revocation list, or CRL. For the CISSP examination, you should be aware of the difference between a suspension, a temporary hold on credentials, and a revocation, where the credentials are gone forever.

Once the credentials are revoked, they cannot be reinstated, and a new certificate would have to be issued. A certificate also has an expiration date, a specific period of time that it is valid for, and after that time the certificate is no longer valid. There is a process to renew certificates, however this is not considered secure.

So typically once a certificate expires a new one is issued rather than renewing the old one. We also must consider a destruction process in order to destroy compromised keys or keys that have reached the end of their life cycle. We must determine where we are going to store the user's private key.

Will the administrator store a copy of the key or will the user have the only copy? We should consider the potential loss of credentials, or a misuse of credentials, by an unauthorized party. Because if an unauthorized user obtains they key, then this defeats the purpose of the public key infrastructure system.

We do have the option to keep a copy of the key in escrow, to recover the key later if necessary. This can be used if the user loses their copy of their private key, but it's typically used for government agencies to decrypt data once they obtain a court order. Here we can decrypt anything that the user has encrypted as long as we have access to the key in escrow. This is popular as well with employees who leave a company, the administrators are then able to decrypt any data that that employee has left behind in an encrypted format.

We can also use a key recovery agent, or KRA, which is an authorized party that we have hold our encryption keys in case of a loss of a key, or a court order, or some other reason that we need to obtain a copy of the keys. Typically, this should involve segregation or separation of duties where you must have at least two administrators involved in order to recover someone's private key.

You can also perform a split knowledge where you actually only give half of the key to one company and the other half of the key to the other company. In this case, neither of the companies would be able to decrypt any of the sensitive data. However one of the authorized administrators could obtain half of the key from the one company, and the other half of the key from the other company, and then access any data necessary.

We typically embed a user's public key in their digital certificates. Digital certificates are created using the X.509 standard. And you should remember that for the CISSP examination. One easy way to remember this is that there are nine letters in the words public key and that X.509 standard that goes with digital certificates ends in the number nine.

So this is an easy way to remember that. Typically, we store digital certificates in a central location to make it easy to encrypt data as necessary. We can store a user's private key on their local machine or we could encrypt it and keep it on some type of device such as a CAC, which is a common access card used by the Department of Defense.

Since it is so important to keep a user's private keys secure, we typically keep them offline to protect them from being stolen by an unauthorized individual. One of the issues with using a software based solution is that an attacker may be able to obtain a copy of the key without permission.

We can also use hardware devices to store keys, such as a crypto module, or a TPM, or trusted platform module. And these devices are considered to be more secure than storing the device in a software based solution. Whenever we have a compromise, it is critical to revoke the credentials immediately and notify all of the appropriate parties that a compromise has occurred.

Our digital certificates provide a secure way to authenticate an individual or a system, and allow us to exchange public keys. When a digital certificate has been compromised it is critical to make sure that we revoke it in order to avoid unauthorized users pretending to be a different user that they are not.

When we're checking the user's identity through a certificate authority we are going to check to see if the serial number for that certificate has been revoked, and if it has not been revoked then we assume it is still valid. We have two ways to do this. A CRL, or certificate revocation list, is a file which contains a list of all of the suspended certificate serial numbers. We can access this information through our email system or a web browser to check the status of a certificate. But we must be able to contact the certificate authority in order to make a verification of a certificate. If we can not verify the identity then the user will see an error message.

A newer technology used for verifying digital certificates is OCSP, or the online certificate status protocol. It's more modern than the traditional certificate revocation list. And here we use a validation authority where we can check a single record for a specific certificate rather than downloading an entire list of revoked certificates.

So it tends to be a much more efficient process. For the CISSP exam you should be familiar with the certification revocation list as well as the online certificate status protocol, or OCSP. And be aware why it is important to revoke credentials that are compromised to ensure the security of our systems.

This concludes our public key infrastructure module. Thank you for watching.